-
Notifications
You must be signed in to change notification settings - Fork 158
Composefs soft reboot #1828
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Composefs soft reboot #1828
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request introduces support for soft reboots for composefs deployments, a significant feature that aligns its capabilities more closely with ostree. The changes include a new internal command for preparing the soft reboot, logic to determine soft reboot capability based on kernel state, and an updated mechanism for detecting the booted deployment after a soft reboot by inspecting the root mount source.
Overall, the implementation is well-thought-out. However, I've identified a couple of critical issues. One is an error handling bug where a failure in the exec call for systemctl soft-reboot would be silently ignored. Another is a logic error in the usage of OnceLock which would fail to detect a soft reboot correctly on subsequent calls. I've also provided a suggestion to refactor a section of the code to improve its conciseness and readability. Addressing these points will enhance the robustness and maintainability of this new feature.
45d51d9 to
a1a0e0f
Compare
|
Is this related to |
| let verity_from_mount_src = root_mnt | ||
| .source | ||
| .strip_prefix("composefs:") | ||
| .ok_or_else(|| anyhow::anyhow!("Root not mounted using composefs"))?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hum...I'm OK with this but ultimately I think it'd be even nicer to have truly structured metadata associated with the mount point somehow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't the fsconfig string be that metadata?
| // This is of the format composefs:<composefs_hash> | ||
| let verity_from_mount_src = root_mnt | ||
| .source | ||
| .strip_prefix("composefs:") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we strongly associate this string with the thing that creates it via a const?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanted to, but it's done in composefs-rs. Maybe we can export it from there
| host.spec.boot_order = BootOrder::Rollback | ||
| }; | ||
|
|
||
| // Can only soft reboot non UKI boot entries |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is a little bit more complex, as we'd have to extract .linux and .initrd sections to compute the hash. Definitely possible though. That being said, in the confidential clusters use case, would soft rebooting be a thing anyway?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We want to support sealed systems outside of just confidential workloads.
It is a little bit more complex, as we'd have to extract .linux and .initrd sections to compute the hash.
There are other UKI components too - such as the critical .cmdline. I think what we really need to do here is a complete diff the two, just dropping out composefs= from the .cmdline or so.
It's a flake (well, a bug somewhere), I'll ensure we have an issue for it |
a1a0e0f to
a4a3840
Compare
This comment was marked as outdated.
This comment was marked as outdated.
|
Hmm...right I think we need to use pull_request_target for the rebase helper |
|
I have rebased it locally. Working on soft-reboot for UKIs |
Signed-off-by: Pragyan Poudyal <pragyanpoudyal41999@gmail.com>
`target` field in Args was not being used. Use it if it is passed in the args. Also helps us mount the new root at `/run/nextroot` Also, use Cmdline struct instead of String to represent the kernel command line Signed-off-by: Pragyan Poudyal <pragyanpoudyal41999@gmail.com>
Add an internal command for soft rebooting the system. Similar to how it's done for ostree, we only allow soft reboot if the other deployment has the same kernel state, i.e. the SHASum of kernel + initrd is the same as that of the current deployment. soft reboot is not possible in case of UKI deployment Signed-off-by: Pragyan Poudyal <pragyanpoudyal41999@gmail.com>
After a soft reboot the kernel cmdline doesn't change so we can't rely on the `composefs=` parameter in the cmdline. Instead, we check the source of the root mount point Signed-off-by: Pragyan Poudyal <pragyanpoudyal41999@gmail.com>
Signed-off-by: Pragyan Poudyal <pragyanpoudyal41999@gmail.com>
Similar to what we do with Type1 entries, we save the SHA256Sum of .linux + .initrd sections of the UKI under `boot_digest` key in the origin file Signed-off-by: Pragyan Poudyal <pragyanpoudyal41999@gmail.com>
Similar to soft reboots for Type1 entries, we compute the SHA256Sum of .linux + .initrd sections in the UKI, and compare them to check for kernel skew Next, compare the .cmdline section skipping the `composefs=` parameter as that will always be different Signed-off-by: Pragyan Poudyal <pragyanpoudyal41999@gmail.com>
a4a3840 to
33c84f1
Compare
Requires: containers/composefs-rs#198 and a bump to
composefs-rsAdd an internal command for soft rebooting the system. Similar to how
it's done for ostree, we only allow soft reboot if the other deployment
has the same kernel state, i.e. the SHASum of kernel + initrd is the
same as that of the current deployment.
Similar to soft reboots for Type1 entries, we compute the SHA256Sum of
.linux + .initrd sections in the UKI, and compare them to check for
kernel skew
Next, compare the .cmdline section skipping the
composefs=parameteras that will always be different
After a soft reboot the kernel cmdline doesn't change so we can't rely
on the
composefs=parameter in the cmdline. Instead, we check thesource of the root mount point